A typical mobile operator comprises two or more operating partners, each of which offers bespoke network services. As a result the operating partners, viewed as a whole, often comprise different and diverse services and corresponding service equipment. The responsibility for development, integration and operation of the network services lies within each individual operating partner, and providing this variety is typically extremely costly for the operator when viewed as a whole, since the costs associated with developing, supporting and marketing the various services can be significant. Moreover, when faced with the task of integrating various network services, the network operator has several awkward problems to overcome, not least due to the fact that legacy service applications are typically not upward compatible, and, as already mentioned, many of the network services are developed and administered by different service providers.
FIG. 1 is a schematic diagram showing a conventional mobile network arrangement comprising a Mobile Station MS, serving node switch network component MSC, and Home Location Register HLR, together with various nodes IN1, IN2, IN3, each arranged to provide an Intelligent Network service. The MSC is arranged to send messages to, and receive messages from, the service nodes IN1, IN2, IN3 in accordance with service parameter data received from the Home Location Register HLR upon registration of the Mobile Station MS with the MSC or in accordance with settings that are statically configured within the home network. While the MS is registered with the MSC, the MSC monitors for occurrences of service triggers (so-called Detection Points (DP)), and, when a trigger is identified, the switch MSC contacts whichever service node is associated with the trigger. In some known systems, each service IN1, IN2, IN3 operates independently of one another (e.g. each service may be provided by a different service provider), and it is often the case that different services are designed to respond to the same trigger. Typically, in such situations the MSC simply activates one of the network services, thereby effectively failing to provide the MS with the other services. International patent publication number WO97/50232 describes a system that is designed to mitigate this problem, and describes a network having a so-called mediation point, which has access to services corresponding to the same trigger, together with rules determining interoperation thereof, and controls invocation of the various services from a single point. However, WO97/50232 requires applications to be categorised into simple classifications and only allows a preconfigured and tabulated set of interactions between services, which is prescriptive and inflexible. Furthermore, each service can only be invoked in accordance with the rule, i.e. once only in respect of a given trigger.
In addition to the existence of different service nodes competing for the same trigger, technical convergence between the telecommunications, computing and multimedia domains has given rise to a new environment for the development and provision of telecommunications services. This has compelled both telecom operators and service providers to develop and deploy new residential and enterprise services and applications. To meet this challenge operators and service providers have sought to replace closed, proprietary systems with standardised, open, interoperable and common platforms, and at least some of the aforementioned services are embodied on such open platforms.
Parlay is an open multi-vendor consortium formed to develop such open technology independent APIs, enabling Internet Service Vendors, network device vendors, software developers, service providers, ASPs and enterprises to create applications that can run across multiple mobile and fixed carrier networks. The Parlay/OSA (Open Service Architecture) standard defines an API (application programming interface) that is technology agnostic and configured to use protocols and technologies such as SIP (Session Initiation Protocol), JAIN (Java APIs for Intelligent Networks) and Web Services to communicate with third party devices and services in different domains.
Whilst this framework has greatly improved the interoperability of services, there are, nevertheless, implementation issues associated with disparate services registering for interest in network events. In the following description is it assumed that “an application/service registering for interest in . . . ” means “an application/service is arranged to react to . . . ”, and that “a network event” means, for example, a trigger from the network (or indeed another service or application node) in respect of a specified destination and source address.
There are currently 14 Service Control Functions (SCF), including various generic call control (GCC) and multi party call control (MPCC) SCFs; between them, the GCC/MPCC SCFs map to all of the Intelligent Network (IN) messages, and can therefore invoke all of the network capabilities. Using the Parlay APIs, any given service can register and deregister for network events (by means of e.g. for GCC SCFs, enableCallNotification( ) and disableCallNotification( ) methods respectively and for MPCC SCFs, by means of createNotification( ) and destroyNotification( ) methods respectively) each registration request corresponding to one or more subscribers (source address) and/or destination address(es) (e.g. a specified number in the case of number translation services). A simplified representation of the network and OSA domains is shown in FIG. 2, and an example of the routing of GCC registration messages between OSA and network devices is shown in FIG. 3. In this example an application App1 is arranged to check the balance of specified subscribers prior to allocation of network resources, and accordingly App1 invokes the enableCallNotification( ) method each time it determines that a subscriber's balance needs checking prior to allocating network resources in respect of the requested service. This results in a MAP AnyTimeModification( ) message being sent to the HLR in order to activate the necessary subscription information (O-CSI, D-CSI (activated in relation to the subscriber's address)). Having successfully registered for this network event, when such a specified subscriber subsequently requests a service (i.e. O-CSI (data identifying the subscriber)), App1 is invoked and used to control at least the initial part of the service provision procedure.
The enableCallNotification( ) method is purely intended for applications to indicate their interest to be notified when certain call events take place. It is possible to subscribe to a certain event for a whole range of addresses, e.g. the application can indicate it wishes to be informed when a call is made to any number starting with 800. If an application has already requested notifications with criteria that overlap the specified criteria, the request is refused with, for example, P_GCCS_INVALID_CRITERIA for a GCC registration message and P_INVALID_CRITERIA for an MPCC registration message. The criteria are said to overlap if both originating and terminating destination addresses overlap and the same number plan is used and the same CallNotificationType (e.g. network trigger) is used. As a result, in most configurations only one application can place a request for a given set of criteria.
British Telecommunications Exact Technologies has identified that having a hard and fast rule of “any overlap-no-co-existence” is overly restrictive and has presented a solution whereby the Parlay GW comprises a Policy Management Service Capability Function (SCF), arranged to cooperate with the Call Control SCF shown in FIG. 2 when an application attempts to register with the gateway. Their Policy Management SCF manages a store of user profiles in which details of services to which a given subscriber has access, together with the respective trigger events, are stored. The user profiles are populated only after the Policy Management SCF has checked that applications can co-exist, their co-existence having been checked by means of a feature interaction processing function which is provisioned with meta-data specifying application interaction rules (so-called “feature interaction” rules). This solution therefore requires rules specifying interactions between applications and services to be pre-stored and accessible in response to application registration requests. When a network event is subsequently received from the network, the Call Control SCF accesses whichever user profile corresponds to the subscriber associated with the network event and retrieves details of applications and services stored therein, controlling their respective invocation sequentially. There are several problems with this solution, not least resulting from the fact that registration requests are resolved in view of that/those application(s) that have already registered. The short comings of this solution can be seen from consideration of the following scenario, in which a first application A has registered for the user, the user profile having been updated to include data indicative of application A. If a registration request is subsequently received from application B, and if the interaction rules indicate that A is incompatible with B the registration request from application B will fail. If, subsequently, application A de-registers for the subscriber, there is no means of re-capturing application B, even though there is now no reason why the subscriber cannot receive service from application B.
It is an object of the invention to provide an improved level of integration and flexibility for network services.